Include page path in PageData.vars error messages#242
Include page path in PageData.vars error messages#242
Conversation
When a page's vars module throws (syntax error, missing dependency, runtime error), the vars getter propagated a bare error with no indication of which page failed. In global.data.js and templates, this forced users to wrap every .vars access in try/catch and silently swallow errors, hiding which page was broken. The getter now catches any error at access time and re-throws with the page path included in the message, making it easy to locate the offending page without bisecting a large site.
Coverage Report for CI Build 24619532678Coverage remained the same at 91.469%Details
Uncovered ChangesNo uncovered changes found. Coverage RegressionsNo coverage regressions found. Coverage Stats
💛 - Coveralls |
There was a problem hiding this comment.
Pull request overview
Improves debuggability of page variable resolution by adding page path context to errors thrown from the PageData.vars getter, making it easier to identify which page’s vars module caused a failure during builds.
Changes:
- Wrapped
PageData.varsgetter intry/catchto intercept resolution/merge failures. - Re-threw a new error whose message includes
pageInfo.path, preserving the original failure ascause.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
Acknowledged comment 3105591230. Declining to add tests in this PR for the following reason: testing the |
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Covers the two uninitialized-access paths: one where pageInfo has a path (error message should include it) and one where it does not (fallback to '<unknown page>'). Both guard against regressing the page-context diagnostic improvement added in the vars getter. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
This looks good to land. |
Closes #233
When a page vars module throws (syntax error, missing import, runtime exception at access time), the
varsgetter re-threw the error with no context about which page caused it. On a large site with pages spanning many directories, finding the broken page required manually bisecting the whole tree.This wraps the getter body in a try/catch and re-throws with the page path included in the message:
The original error is preserved as
causeso nothing is lost. The fix only adds context to errors that were already being thrown; it does not change any behavior for pages that resolve successfully.A side effect is that users who previously had to write defensive
try/catchwrappers around every.varsaccess inglobal.data.jsand templates will now get actionable errors instead of silently swallowed ones.